25th oct 2009 monologue of life

so I have an object
should I want to keep a list of them, this would imply each object exists once, no dups; should I want dups imagine the object is encapsulating another subobject ie. char, and thus dups can exist
but the mere idea of having a list of them implies some kind of storage or persistency for these objects
which kinda means, I'm keeping a history or log of the object's birth/changes/death
it's like the list would contain:
1. created o1
2. destroyed o1
those 2 elements
so you'd know when o1 exists in list and when it doesn't (anymore)
but holding state+obj in a list is already a next level to a simple list that hold just objects; it seems.
so, some kind of a storage system (even if it's in memory or a hashSet or BDB) would be responsible for keeping track of these items in the list, or should it be a Set at the lowest level?
it almost seems like bringing demlinks down to java level...
so whoever holds and manages the Set or list (ie. the storage will) it also need to be able to do searches
how to find an object from a set of objects?
1. by knowing the object, u can pass it to a find(obj) method and return true/false if exists/not
2. by knowing part of the object(ie. maybe some of the components that make this object)
3. by applying some algorithm ie. comparator to each of the objects in the set and this comparator will yield ie. from 0 to 100% as to how much the objects encountered are compared to the target searched object
...

we could merge all those 3 into the 3rd, and have a class run it's default compareWith(current) method on each of the objects in the Set, and when done maybe have a Set of all objects that 
were highest to match this, or depending on the comparator's behaviour, it can even stop when finding first 100% match, and it can find only 0 or 100% matches; or can hold a list of all matched
objects sorted from 100% to 0% after it ran. Or maybe it can be ran on each object insertion/deletion and be like a registered observer to the list's modifications and always hold the updated
sorted list of all elements as specified by itself.

	however on (2.) knowing part of the object should be out of the scope of the list manager, unless all objects are known to follow the same pattern ie. they're all a list of other objects;
but assuming the list manager doesn't know anything about the insides of the objects it holds in list, then it would perhaps just pass the comparator to the object being compared... or hmm.

	so there's an object Storage that has a list of Base objects (but maybe they can be of any type, or rather subType of Base, which in java is the Object class)
and you want to find a Seeker object which is also a type of Base or well similar with those held in the list(or Set), so you pass this object to the Storage and ask it to produce a list of
candidates for you, which could be just 1 object that's 100% equal to the Seeker object, but I mean .equal() as contents not == as references, 'cause chances are the Seeker object is a totally
new object made just for the purpose of finding the object with specific contents, well Seeker could be a static object already allocated with new() and only its contents changed on each search
attempt, so we don't make a new Seeker object every time we search(would be bad in java perhaps, with the delayed garbage collector, would use up ram, supposedly)
   the Seeker object would contain the whole or part of the object we try to find in the Set, it should be the same type as the object(s) in the Set; we're not yet sure if the objects in the set 
and also the Seeker are all the same type, or of different types as long as each type is a subclass of Object. For example the Set may contain 2 objects one String and one Integer, and the Seeker
could be a String and thus we would only look for String objects in the set while trying to find this Seeker, however we won't know if String is a subclass of Integer and therefore maybe any 
subclasses of the Seeker object are valid to be found... perhaps this comparison of classes should be left to the comparator instance that is passed along with the Seeker object to a 
Storage.find() method; assuming Storage is the one holding the list/set.

-------


  